home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000095_news@newsmaster….columbia.edu _Tue Oct 14 16:47:15 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA01809
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 14 Oct 1997 16:47:15 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA21803
  7.     for kermit.misc@watsun; Tue, 14 Oct 1997 16:47:14 -0400 (EDT)
  8. Path: news.columbia.edu!sol.ctr.columbia.edu!news.indiana.edu!vixen.cso.uiuc.edu!uwm.edu!news.sprintisp.com!sprintisp!news-peer-west.sprintlink.net!news-peer.sprintlink.net!news.sprintlink.net!Sprint!newsfeed.internetmci.com!164.67.42.145!awabi.library.ucla.edu!134.87.113.1!news.bc.net!rover.ucs.ualberta.ca!alberta!not-for-mail
  9. From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Date: 14 Oct 1997 14:25:55 -0600
  13. Organization: University of Alberta, Computing Science
  14. Lines: 43
  15. Message-ID: <omn2kcqegc.fsf@tees.cs.ualberta.ca>
  16. References: <k1c7kBQEU5Wv@cc.usu.edu> <omvhza9x7g.fsf@tees.cs.ualberta.ca>
  17.     <5jzp7SiZjuUm@cc.usu.edu>
  18. NNTP-Posting-Host: tees.cs.ualberta.ca
  19. In-reply-to: jrd@cc.usu.edu's message of 12 Oct 97 15:22:13 MDT
  20. X-Newsreader: Gnus v5.0.15
  21. Xref: news.columbia.edu comp.protocols.kermit.misc:7873
  22.  
  23. In article <5jzp7SiZjuUm@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  24.  
  25. > >> >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
  26. > BOOTP and DHCP require a local MAC address to work with, SLIP has no MAC
  27. > address
  28. Ok, now: Is BOOTP availability over PPP links sufficient incentive  to warrant
  29. pursuing this issue? 
  30.  
  31. > continue the conversation with the authors of those drivers and see if they
  32. > will reveal the extent to which they perform the required emulation.
  33. Ok, I'll try that.
  34.  
  35. >     Proxy ARP et al have not the slightest to do with Kermit (or other
  36. > client) internals. That is outside of and unknowable to these clients.
  37. I know that. I was trying to figure out how does class 1 emulation work.
  38.  
  39. For a PPP link, Kermit`s job is pretty simple: it has to send all it wants to
  40. send down the link, without caring mcuh about MAC addresses. That's why I
  41. think it would be an easy fix: Kermit could simply disregard some of its
  42. "doubts" about the faithfulness of the class 1 emulation and just go ahead.
  43.  
  44. > MSK will report 
  45. > 1. if it is unable to register with the Packet Driver for IP and ARP packets
  46. > 2. if another station responds to an ARP for MSK's own IP address,
  47. > 3. and if it is unable to receive a response to an ARP.
  48. This is the kind of info I need to figure it out (if at all possible from
  49. external observation only). Does the message "Unable to ARP resolve" mean item
  50. 3 above? Will these conditions appear in the order listed, so can I assume
  51. that 1 and 2 do not happen?
  52.  
  53. > If those conditions are met and the driver proclaims to be Ethernet then the
  54. > driver had better behave like Ethernet...  Kermit does tell you if
  55. > interfacing conditions fail 
  56. What other errors can happen from that point on? (Ok, perhaps this is a stupid
  57. question :-) Can you think of other interfacing conditions that can fail,
  58. apart from the listed 3? 
  59.  
  60. > it cannot tell anyone about Ethernet simulation failures in an external
  61. > driver.
  62. I was hoping that we can figure out what more does Kermit expect from a class
  63. 1 emulator compared to other TCP apps (and you're starting this, with the 3
  64. conditions above). Now I'll try from the other end, ask emulator authors what
  65. less do these emulators provide compared to true ethernet drivers.